In prior approaches to block based incremental backup a trade-off typically had to be made between tracking and logging in a persistently-stored change block log all blocks modified since a previous backup, which would enable incremental backups to be performed even after system reboot and/or crash but which consumed resources (e.g., time, storage) and potentially could impact performance, and not tracking changed blocks in a persistently-stored log, which resulted in a full backup operation being required in the event of a system reboot and/or crash.